The exponential rate of growth of the World Wide Web has led to a dramatic increase in Internet traffic, as well as a significant degradation in user-perceived latency while accessing “web pages.” Web servers store hundreds or thousands of pages each of which consist of one or more typed resources (e.g., text, in line images, applets, etc.). As the popularity of the web increases, these servers support an increasing number of requests to transfer resources and validate copies that are cached in other locations. For instance, as shown in FIG. 1 of the present application, a client at computer 101, which can be a personal computer, laptop or other known computing device, is connected to a data network gateway, in this instance an Internet service provider (ISP) 102. The gateway provides access to the data network, here Internet 103. Within the data network there are a plurality of resource servers, e.g., 104 and 105, which store content or resources which may be of interest to various clients. To facilitate access by a client to a particular resource, the gateway or ISP may have associated therewith a cache structure. An example of such a structure is shown as proxy cache 106. The cache would be constituted by a memory structure which can store resources after they have been retrieved from a resource server. For instance, as shown in the flow diagram of FIG. 2, the ISP may receive a resource request, step 200. Before accessing a resource server in the Internet the ISP can check its proxy cache 106 to determine whether it has a valid copy of the requested resource, step 201. It may determine whether it has a valid copy of the resource by first determining that it has a copy of the resource in the cache at all and then determining the freshness of the resource. This latter characteristic of the resource may be determined in part based upon information associated with the resource in the proxy cache such as information identifying the time that the resource was last retrieved from one of the resource servers. This technique of keeping track of a time to live (TTL) for the resource provides some estimate of the likelihood that the resource within the proxy cache is still fresh or has been modified. If it is determined that the cache has a valid copy of the resource then the ISP can send a copy of the resource to the requester without submitting the request out into the Internet to the resource server, step 202. If the proxy cache does not have a valid copy of the resource then the ISP will send a request for a resource to a resource server, step 203. The resource server would then send a valid copy of the resource back to the ISP acting as a proxy server which would in turn would both send the resource to the requester and cache the resource in the proxy cache, steps 204, 205 and 206.
It is known to modify the above method to provide even stronger cache coherency by sending a request to validate the copy of the resource in the proxy cache. In this circumstance, the proxy server may either determine that the resource does not appear fresh or opt in all circumstances to send a resource identifier to the resource server asking the resource server to send the resource back to the proxy server if the resource has been changed since the last time that the proxy cache validated the resource. In the TCP/IP environment this is referred to as a GET-If-Modified-Since request. In this circumstance then the resource server can either advise the proxy cache that the resource maintained in the proxy cache is still valid or alternatively if the resource is no longer valid can send a fresh copy of the resource in response to the request.
It should be noted that data transfers on the network links impart a heavy load on not only those links but on the routers between the servers and the client sites. The round-trip delays in establishing a TCP connection and initiating a request, as well as the waiting time at the server and the limited network bandwidth for transferring the response message, translate into user-perceived latency. While caching resource information in proxy caches may somewhat reduce this latency, the validation procedures known in the prior art still introduce substantial loads on the network resources thereby introducing possible-choke points or delays.
In a related application assigned to the same assignee as the present application, entitled “Method for Cache Validation for Proxy Caches” filed on Dec. 30, 1997 it was suggested that network performance could be improved by piggybacking additional requests for resource validation upon a request for a particular resource asked for by a client. In particular, in this related application when the proxy server received a request for a resource, the proxy server might determine which other resources present in its cache were received from the same resource server as the client requested resource. Then the proxy server would forward a request for validation with respect to the client requested resource and a request for validation with regard to one or more additional resources in the proxy cache that were from the same resource server. A return message from the resource server would include information about the client requested resource as well as information about the additional resources identified in this piggyback cache validation signal. While this approach is a benefit to the proxy cache in the sense that it helps the proxy cache determine the validity of certain of its contents at an earlier time, that method does not take into account the notion that when a client requests a first resource there is a substantial probability that there is a particular subset of additional resources which might be requested by the same client following the initial request. This subset of additional resources is related to the initial request either in content or by its location. It would be beneficial if a technique could be provided by which the proxy cache-validation techniques could take advantage of the likelihood that certain resources are sufficiently related to one another such that one or more additional resources are likely to be requested after the first resource is requested.
In accordance with an embodiment of the present invention resources can be grouped together into volumes. The resources in a given volume are deemed to be related to one another according to one or more criterion. In particular, it is possible that all of the resources of a given volume are related to one another based on a given directory level in the path name. Alternatively, resources could be grouped together in a volume based on a probabilistic determination that once a given resource has been requested it is likely that the additional resources in the volume will also be requested. Another possible criterion relates to the content type of the resource. It is also possible that a given volume can be constituted by resources from two or more resource servers. Furthermore, it is also conceivable that all of the resources at a given resource server could be considered to constitute a single volume. In accordance with an embodiment of the present invention when the proxy server sends a resource request to either a resource server or to a volume center which acts on behalf of a set of resource servers, it also sends a proxy filter with the request. The proxy filter identifies certain criteria of interest to the proxy server with regard to any additional resources which might be in the same volume as the requested resource. Upon receipt of the resource request and proxy filter the resource server or volume center selects one or more additional resources from the volume associated with the requested resources utilizing the criterion identified in the proxy filter. A resource request response is then generated and sent back to the proxy server. Appended to that response is information about additional resources selected from the volume using the proxy filter criteria. The proxy server, upon receipt of this information from the resource server or volume center can then forward the appropriate requested resource to the requesting client and can update its proxy cache to indicate the extent to which already cached resources are valid or invalid. It can also make a determination whether to pre-fetch any of the additional resources identified in the appended additional information.
Further details with regard to an embodiment of the present invention and alternative configurations within the embodiment will be described in the detailed description that follows.